Architecture

Itential Automation Platform (IAP) integration takes place via REST APIs that reside just above the business logic layer. These APIs expose the full functionality contained in the business logic layer to both IAP and third party applications.

Layer	Description
Application	User interfaces and additional business logic not provided by the business logic layer.
Business	Business logic that is reusable across applications.
Broker and Adapter	Abstractions and integrations with southbound entities. Supplies important core functionality.

Application Directory Structure

IAP applications that include both server-side and client-side code.

The following is an example application directory structure.

Application Layer

The application layer provides client-side user interface code. Each application is loaded as a module into IAP at runtime. In addition to managing user interactions, the application layer ensures user interactions are appropriately applied to the system by making API calls to the business logic layer. An application, and its business logic, are tightly coupled.

The following is an example of the components relevant to this layer. The pronghorn.json file exposes client-side HTTP routes.

The following table includes descriptions of directories relevant to this layer.

Directory	Description
img	Images loaded by the client browser.
scripts	Code that is executed by the client browser.
style	Client-side styling.
views	Client-side view code.

Business Logic Layer

The business logic layer provides re-usable business logic. Each application loaded into IAP adds a business logic module. Every method defined in this layer has a REST API interface allowing a consumer to invoke calls from the user interface, IAP applications like Workflow Engine, or any external third party integration.

Each business logic program uses various brokers and adapters to perform its duties.

Note: Care should be taken to adhere to the standards of a REST API interface when performing business logic design.

The following is an example of the components relevant to this layer.

The following table includes descriptions of files relevant to this layer.

File	Description
cog.js	NodeJS code that executes on the IAP server.
pronghorn.json	Exposes server-side JavaScript functions and workflow tasks.

Adapter Layer

The adapter layer allows IAP to communicate with third party APIs. The responsibility of the adapter is to return normalized data objects to IAP based on the results of third party calls. To reference an object-oriented analogy, the adapter represents the class component of the interface-class relationship. Many adapters can support a single broker. For example, adapters for NSO, OpenDaylight, and ONOS can support the device broker.

IAP loads all adapters as modules during startup and before loading the application modules. Each Adapter will contain a minimum of three files.

• package.json
• pronghorn.json
• src.js

Broker Layer

The broker layer provides a common, abstracted interface for related adapters. It fundamentally establishes the set of available function calls to be implemented in adapters. To use an object-oriented analogy, a broker can be thought of as an interface definition of the interface-class relationship. A broker typically has a one-to-many relationship with adapters. Another responsibility of the broker layer is to ensure consistency between data models across various adapters.

IAP currently supports the following brokers.

• AAA
• Compliance
• Device
• Fault
• Instance
• Inventory
• Notification
• Performance
• Persistence
• Service
• Topology

All broker implementations live in the pronghorn-core/brokers directory. Each broker consists of a minimum of two files.

• pronghorn.json
• src.js

The pronghorn.json file is used to define the possible broker calls.

{
  "id": "DeviceBroker",
  "type": "Broker",
  "methods": [
    {
      "name": "locateDevice",
      "summary": "",
      "description": "",
      "input": {},
      "output": {}
    }
  ],
  "encrypted": false
}

The properties.json file may contain configuration for all brokers.

{
    "brokerProps": {
        "device": [
            {
                "id": "Mock Device",
                "type": "MockDevice",
                "properties": {
                    "groups": [
                        "circle, square, triangle"
                    ],
                    "deviceCount": 1
                }
            }
        ]
    }
}

The src.js file provides the broker's implementation.

/* global log */
/* global adapterClasses */
const util = require('util');
const fs = require('fs');
const Discovery = require('@itential/itential-utils/Discovery').Discovery;
const discovery = new Discovery();
const Broker = discovery.require(__dirname + "/../broker.js", pronghornProps.pathProps.encrypted);
var getNamespace = require('continuation-local-storage').getNamespace;
var namespace = getNamespace('itential.pronghorn');

/**
 * Device Broker
 * @constructor
 * @param {object} adapters - Array of adapters used as providers.
 */

const DeviceBroker = function (adapters, model) {
  Broker.apply(this, arguments);
  this.devices = {};
  this.groups = {};
  this.device_map = {};

  adapters.forEach(function (adapter) {
    if (adapterClasses[adapter.type]) {
      this.providers[adapter.id] = new adapterClasses[adapter.type](adapter.id, adapter.properties);
    }
  }, this);
};

util.inherits(DeviceBroker, Broker);

/**
 * Find the host for a given device
 * @memberof DeviceBroker
 * @param device {string} - unique name of the device
 * @param callback {function} - Callback to be called when this function completes
 */
DeviceBroker.prototype.locateDevice = function (device, callback) {
  this.getDevices(function (devices) {
    let location = null;
    devices.forEach(function (element) {
      if (device == element.name) {
        location = element.host;
      }
    }, this);
      callback(location);
  });
}

East / West Interfaces

The East and West interfaces allow IAP to be integrated with other existing OSS and BSS systems. For example, a billing system may trigger service activation via an East or West integration.

Workflow Engine

The Itential Workflow Engine (WFE) allows IAP to automate tasks. This is a powerful component that provides a mechanism to automate tasks while reaping the benefits of manual review and decision-making processes where necessary or desired. Workflows are defined by customers or a third party integrator. Any of the API calls defined in the business logic layer are available to be called as workflow tasks thereby providing a robust set of features to the workflow designer. Last, workflow processes can be defined for new service provisioning, service relocation, and many other scenarios.